System for terminating multicast channel and data broadcast when at least two second endpoints do not transmit positive acknowledgement message to first endpoint

ABSTRACT

A method and apparatus for optimizing transmission of data to a plurality of second endpoints in a system wherein a first endpoint is providing data to the plurality of second endpoints each connected by a point-to-point communication channels. This may be useful in teleconferencing applications with a plurality of participants (endpoints) or broadcast server applications. The first endpoint activates a multicast communication channel having a first multicast address and commences broadcast of the data over the multicast communication channel. The first endpoint transmits a request message to each of the plurality of second endpoints in order to query each of the second endpoints whether they can receive transmissions broadcast to the first multicast address. Certain of the plurality of second endpoints transmit an acknowledgement message if they can receive transmissions broadcast to the first multicast address, and the first endpoint receives the acknowledgement message. Then, for each acknowledgement message received from certain of the plurality of second endpoints, the first endpoint deactivates the point-to-point communication channel and the certain of the plurality of second endpoints.

Notice: More than one reissue application has been filed for the reissueof U.S. Pat. No. 5,999,977. The reissue applications are applicationSer. Nos. 10/020,515, 10/857,798 (the present application), 10/857,799,10/857,805, and 10/857,806.

This is a continuation application of U.S. Reissue Application No.10/020,515, filed Dec. 7, 2001, which is a reissue application of U.S.Pat. No. 5,999,977, issued Dec. 7, 1999, which is a continuation of U.S.patent application Ser No. 08/468,715, now abandoned, filed Jun. 5,1995, which is a continuation of U.S. patent application Ser. No.08/396,198, filed Feb. 24, 1995, now U.S. Pat. No. 5,854,898 issued Dec.29, 1998.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to teleconferencing systems.

More specifically, the present invention relates to the addition of adata stream, such as an auxiliary data stream to a teleconference.

2. Background Information

Teleconferencing is increasingly becoming a popular application inpersonal computer systems. Such applications typically allow thetransfer of audio and video data between users so that they can speakand otherwise communicate with one another. Such applications sometimesalso include data sharing wherein various types of data such asdocuments, spreadsheets, graphic data, or other types of data, can beshared and manipulated by all participants in the teleconference.Different teleconference applications perhaps residing on differenthardware platforms have different capabilities. Moreover, a wide varietyof features has been implemented in different teleconferenceapplications, and the proliferation of different types of computersystems with different capacities, and different networking media hascreated challenges for teleconferencing.

For example, for most teleconferencing applications, it is assumed thatthe sender and the receiver have certain minimum capabilities. However,with the wide diversity of systems having different computationcapacities, and in addition, the wide variety of networking media, thatcertain systems may not have certain capabilities. For example, thefirst system may be a high performance workstation coupled to a highperformance communication medium where as a second system may employ anearlier generation processor, operate at a substanilly slower clockrate, and/or be coupled to a lower capacity communication medium.Certain network capabilities such as multicast or other optimizationfeatures, may not be present in certain networking media. Thus, in orderfor some teleconference applications to function, the participants inthe conference can only operate at the fastest possible configurationprovided by any minimum system which may participate in theteleconference. Of course, this results in certain inefficiencies,especially if both of the participants are capable of transmitting in ahigher capacity than the system with the least possible capability.

Another issue in teleconference applications is the ability of certainstations to participant in more than one teleconference. In fact, incertain circumstances, multiple individual conferences may be desired tobe merged by a user according to operating circumstances. Due to thedistributed nature of certain networks, during this merge operation,certain circumstances may change. That is, that while a single stationis merging more than one conference it is participating in, a secondstation at a remote location may further have other operatingcircumstances changing (e.g., participants leaving, entering, orotherwise joining an on-going teleconference), and thus, the managementof such merging operations becomes unduly burdensome.

Yet another shortcoming of certain prior art teleconference applicationsis the ability to associate an independent data stream with an on-goingteleconference. For example, a source participant may desire to providean additional data stream to other participants in a teleconference.This additional source may include, but not be limited to, video, data,audio or any other type of data available to the source participant. Forexample, such an additional source may include other audio informationfor a receiver. Other types of data may aslo be desired to be associatedwith an on-going teleconference, which may be accessible to otherparticipant in the teleconference. Certain prior art teleconferencingapplications lack these abilities.

SUMMARY

A method and apparatus for optimizing transmission of data to aplurality of second endpoints in a system wherein a first endpoint isproviding data to the plurality of second endpoints each connected bypoint-to-point communication channels. This may be useful inteleconferencing applications with a plurality of participants(endpoints) or broadcast server applications. The first endpointactivates a multicast communication channel having a first multicastaddress and commences broadcast of the data over the multicastcommunication channel. The first endpoint transmits a request message toeach of the plurality of second endpoints in order to query each of thesecond endpoints whether they can receive transmission broadcast to thefirst multicast address. Certain of the plurality of second endpointstransmit an acknowledgment message if they can receive transmissionsbroadcast to the first multicast address, and the first endpointreceives the acknowledgement message. Then, for each acknowledgmentmessage received from certain of the plurality of second endpoints, thefirst endpoint deactivates the point-to-point communication channel andthe certain of the plurality of second endpoints.

The broadcast of the data and the multicast communication channel isterminated if at least two of the plurality of second endpoints do nottransmit the acknowledgement messages containing a positiveacknowledgment. In this instance, communication channels are maintainedas point-to-point. Subsequent to commencing broadcast of the data to themulticast address, the first endpoint can receive detach messages fromcertain of the plurality of second endpoints, and if at least two of theplurality of second endpoint are not receiving the data, then the firstendpoint can terminate the broadcast of the data and the multicastcommunication channel. Communication of the data in this instance alsoreverts to point-to-point communication channels.

In implemented embodiment, the acknowledgment message includes a reasonscode which indicates whether the second endpoint can receivetransmissions broadcast to the first multicast address. Also, inimplemented embodiments, prior to the first endpoint activating themulticast communication channel having the first multicast address, itis determined whether the single communication medium supportsbroadcasting to the first multicast address, and if not, multicastcannot be activated.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and notlimitation in the figures of the accompanying in which like referencesindicate similar elements and in which:

FIG. 1 illustrates an example configuration in which various embodimentsof the present invention may be implemented.

FIG. 2 shows a typical teleconferencing display which has both media andnon-media sources displayed during the course of the teleconference.

FIG. 3 shows a single system in which embodiments of the presentinvention may be implemented.

FIG. 4 shows an example architecture of a system employing variousembodiments of the present invention.

FIG. 5 shows a more detailed view of the conference componentillustrated in FIG. 4.

FIG. 6 shows a sequence of typical conference events in a conferencecomponent which are issued to an application.

FIG. 7 shows a typical sequence of steps performed for memberinitialization within the conference component.

FIGS. 8-10 show typical exchanges of messages for different operations.

FIG. 11 shows a detail of a first endpoint establishing ateleconference.

FIG. 12 shows a sequence of steps performed in a second endpointreceiving the messages sent from a first endpoint during theestablishment of a teleconference.

FIGS. 13-25 show details of the messages transmitted between endpointsduring various teleconferencing applications.

FIGS. 26a, 26b, 26c, and 26d show the steps taken for performing mergeoperations.

FIGS. 27a and 27b show the conferences before and after a mergeoperation between teleconferences.

FIGS. 28a-b show a sequence of steps performed by the conferencecomponent during a merge operation.

FIG. 29 shows an example of a merged conferences table within a singleparticipant.

FIGS. 30a-30b shows a sequence of steps performed for converting pointto point connections to multicast connections for a teleconference.

FIGS. 31 and 32 show the adding of an auxiliary source and the messagesduring the adding of the source to an existing teleconference.

FIGS. 33-34 show the details of a sequence of steps performed within aparticipant for adding an auxiliary source.

FIGS. 35-35b show an example sequence of messages which are sent betweena first endpoint and a plurality of other endpoints in a networkingsystem, and showing various messages transmitted therebetween.

DETAILED DESCRIPTION

The present invention relates to networking systems, more specifically,the present invention describes a massaging protocol for establishingand maintaining teleconference connections between a plurality ofparticipants in a networking system. Applications for this include,transmitting application and/or system capabilities between participantsor potential participants in a teleconference, notifying participants ofa teleconference that more than one teleconference should be merged, andaddition of an auxiliary data stream to an on-going teleconference.Although the present invention will be described with reference tocertain specific embodiments thereof, especially, with relation tocertain hardware configurations, data structures, packets, method steps,and other specific details, these should not be viewed as limiting thepresent invention. Various modifications and other may be made by oneskilled in the art, without departing from the overall spirit and scopeof the present invention.

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patentdisclosure, as it appears in the Patent and Trademark Office patentfiles or records, but otherwise reserves all copyright rightswhatsoever. Copyright Apple Computer, Inc.

A typical system configuration in which a teleconference may take placeis illustrated as 100 in FIG. 1. For example, a first workstation 150may communicate via teleconference with a second workstation 155, asillustrated. System 150 may include a central processing unit 150c whichis coupled to a display 150d a video input device 150a, and a soundinput device 150b. The system 150 may communication with over system 155over networking medium 170 via network connection module 160. 160 mayinclude any number of network adapters commercially available such asusing Ethernet, Token Ring, or any other networking standardcommercially available. Note that network adapter 160 may also include awireless network adapter which allows transmission of data betweencomponents without a medium 170. Communication is thus provided vianetwork adapter 165 coupled to system 155, and bi-directionalcommunications may be established between two systems. System 150further has a keyboard 150e and a pointing device 150f, such as a mouse,track ball, or other device for allowing user selections and user input.

A teleconference display is shown at 200 at FIG. 2. In implementedembodiments of the present invention, there is a source window, such as201, showing a monitor of the local media source, and there are othermedia windows, such as 202 or 203 for each other user with which aparticipant is having communication. In the illustrated example, each ofthe windows 201-203 provides media information, that is, real-time audioand/or vide information for bi-directional teleconferencing. Inalternate embodiments of the present invention, non-media informationsuch as 204 may also be displayed within the teleconferencing display.As will become apparent in the description below, in addition to mediaand non-media information, messaging information may also be transmittedbetween stations. In addition, an auxiliary media source (e.g. audio orvideo information) may be transmitted with a specified conference. Thedetails of this will be discussed in more detail below.

In implemented embodiments of the present invention, a general purposecomputer system is used for implementing the teleconferencingapplications and associated processes to be described here. Althoughcertain of the concepts to be described here will be discussed withreference to teleconferencing, it is apparent that the methods andassociated apparatus can be implemented for other applications, such asfile sharing, real time data acquisition, or other types of applicationswhich sends data from a first participant to a second participant or setof participants. A computer system such as that used for implementingembodiments of the present invention will now be described.

A computer system, such as a workstation, personal computer or otherprocessing apparatus 150c or 155c as shown in FIG. 1 is illustrated inmore detail in FIG. 3. 150c comprises a bus or other communication means301 for communicating information, and a processing means 302 coupledwith bus 301 for processing information. System 150c further comprises arandom access memory (RAM) or other volatile storage device 304(referred to as main memory), coupled to bus 301 for storing informationand instructions to be executed by processor 302. Main memory 304 alsomay be used for storing temporary variables or other intermediateinformation during execution of instructions by processor 302. Includedin memory 304 during run-time may be the conference component modulewhich operates according to the communication protocols to be describedbelow. System 150c also comprises a read only memory (ROM) and/or otherstatic storage device 306 coupled to bus 301 for storing staticinformation and instructions for processor 302, and a data storagedevice 307 such as a magnetic disk or optical disk and its correspondingdisk drive. Data storage device 307 is coupled to bus 301 for storinginformation and instructions.

System 150c may further be coupled to a display device adapter display321 such as a cathode ray tube (CRT) or liquid crystal display (LCD)coupled to bus 301 for displaying information to a computer user. Such adisplay 321 may further be coupled to bus 301 for the receipt of videoor image information. An alphanumeric input device 322, includingalphanumeric and other keys may also be coupled to bus 301 forcommunicating information and command selections to processor 302. Anadditional user input device is cursor control 323, such as a mouse, atrackball, stylus, or cursor direction keys, coupled to bus 301 forcommunicating direction information and command selections to processor302, and for controlling cursor movement on display 321. Forteleconferencing applications, system 150c may also have coupled to it asound output device 324, a video input device 325, and sound inputdevice 326, along with the associated D/A (Digital-to-Analog) and A/D(Analog-to-Digital) converters for inputting or outputting media signalbitstreams. System 150c may further be coupled to communication device327 which is coupled to network adapter 160 for communicating with otherteleconferencing stations.

Note, also, that any or all of the components of system 150c andassociated hardware may be used in various embodiments, however, it canbe appreciated that any configuration of the system may be used forvarious purposes according to the particular implementation.

In one embodiment, system 150c is one of the Apple Computer® brandfamily of personal computers such as the Macintosh 8100 brand personalcomputer manufactured by Apple Computer, Inc. of Cupertino, Calif.Processor 302 may be one of the PowerPC brand microprocessorsmanufactured by Motorola, Inc. of Schaumburg, Ill.

Note that the following discussion of various embodiments discussedherein will refer specifically to a series of routines which aregenerated in a high-level programming language (e.g., the C or C++programming language) and complied, linked, and then urn as object codein system 150c during run-time within main memory 304 by processor 302.For example the object code may be generated by the C++ Compileravailable from Symantec, Inc. of Cupertino, Calif.

Although a general purpose computer system has been described, it can beappreciated by one skilled in the art, however, that the followingmethods and apparatus may be implemented in special purpose hardwaredevices, such as discrete logic devices, large scale integrated circuits(LSI's), application-specific integrated circuits (ASIC's), or otherspecialized hardware. The description here has equal application toapparatus having similar function.

FIG. 4 illustrates a plurality of processes and/or apparatus which maybe operative within system 150c. At the highest level, for example, atthe highest level in the ISO/OSI networking model, an applicationprogram 401, such as a teleconferencing application, an audio/videoserver, or a data server, communicates with conference component process400 in the form of Application Program Interface (API) calls. Theconference component 400 allows the application to establishcommunications between two or more teleconference stations. Controlinformation, and media information can be transmitted between the firstparticipant system and a second participant system. The conferencecomponent will be shown in more detail in FIG. 5. Conference component400 communicates with the transport component 402 by sending MovieTalkmessages for other teleconferencing stations which are encapsulated andplaced into a form that the transport component 402, the networkcomponent 403, and the system network component 404 can packetize andtransmit over networking medium 170. For the purposes of the remainderof this disclosure, certain of the MovieTalk API calls and MovieTalkmessages which are transmitted between conference components in ateleconferencing system will be described in more detail.

The transport component 402 and the networking component 403 provide thenecessary operations for communication over the particular type ofnetwork adapter 160 and networking medium 170 according toimplementation. For example, networking component 402 may provide theTCP or ADSP protcols and packetizing, according to those respectivestandards.

A more detailed view of the conference component 400 is shown in FIG. 5.Specifically, the conference component 400 is shown in two portions 400aand 400b which show input and output portions of the conferencecomponent. Although illustrated as a separate transmitter and receiver,each conference component in the system has both capabilities, so thatfull bi-directional communication between conference components inrespective participant teleconference systems in a network maycommunicate with one another. As illustrated, the input portion of theconference component 400a receives video and sound information overmedia input channels 510 and 520. The video channel component and soundchannel component 504 present media data at regular intervals tosequence grabber 502. The real-time sound and vide data (hereinafterreferred to as “media data”) are provided to a source stream director500 from sequence grabber 502 which then provides the media messages tothe transport component 402. Flow Control 501 then lets the video andsound data flow through at an implementation-dependent frequency. Thevideo channel component 503, sound channel component 504, and sequencegrabber 502 all are implemented using prior art products such as thosecommercially available (e.g., the QuickTime video channel, sound channelcomponents, and sequence grabbers, available from Apple Computer, Inc.of Cupertino, Calif.) Flow control 501 may be implemented using knownflow control apparatus and/or method as are commercially available, suchas those which regulate flow based upon bandwidth, and other constraintsin the source participant system. The conference component furthercomprises a sink stream director 510 which comprises a portion of thecomponent 400b of the conference component for receipt of media datafrom transport component 402. Corresponding flow control 511, video andsound stream players 512 and 513, and compression and sound manager 514and 515, for output of video streams 530 and 540, also form part of theconference component for full bi-directional conferencing capabilities.

The conference component's main function is to establish and maintain abi-directional connection between every member of a conference.Conferencing applications use a pre-established control channel toexchange control data that is pertinent to the conference. This datamight include user identification information or other information thatis germane to the application's operation. Conferencing applications(e.g., 401) define the format and content of these control messages byestablishing their own control protocols. The conferencing componentfurther establishes communication channels between a first endpoint anda second endpoint, using the underlying transport component 402. Thus,once a media channel has been established, the conference component usesthe transport component 402's media channel which is provided fortransmission of media and non-media information. For the remainder ofthis application, however, the focus will be on the establishment ofcommunication between a first and second participant (referred to asendpoints) or group of participants which may participate in ateleconference.

Application Program Interface (API)

The application program 401 controls the conference component 400 by theissuance of MovieTalk application API calls. The conference componentoperates using an event-driven model wherein events pertinent to theapplication are issued to the application program. The applicationprogram can then take appropriate action either by modifying internaldata structures within (creating a source or sink), and/or issuance ofappropriate messages over the network to other connected participants,or potential participants. According to messages received by theconference component, a current context and API calls from theapplication, the conference component can take appropriate action.

A typical series of events which occur after the establishment of ateleconference by the conference component in an application isillustrated in FIG. 6 as 600. For example, upon an initial desire by anapplication to enter into a conference (as expressed by an API call) ora call from another participant, a conference-ready event 601 (e.g.mtConferenceReadyEvent) is generated. The application then creates amedia source in the conference component (e.g., member A) which is toprovide the conference information. Subsequent to that, any auxiliarymedia sources may also be attached to the main conference at step 610for a second media source (e.g. by the call MTConferenceAttachAuxiliarySource). Then, any members that are new to the conference are recognizedas being ready by the receipt of MemberReady (e.g. mtMemberReady) events(e.g., 602 and 603 of FIG. 6). This establishes the media sinks such asb and c illustrated in FIG. 6. Then, during the teleconference session,a variety of other events 604 may be issued and acted upon by theconference component. These may include message events, mode events,incoming call events, data transmission events, etc. Members leaving theconference result in the issuance of MemberTerminated (e.g.mtMemberTerminatedEvent) events to the application program such as 605or 606. Thus, for every MemberReady event for any member participatingin a conference, there is a corresponding MemberTerminated (e.g.mtMemberTerminatedEvent) event prior to the end of the conference. Inaddition, the auxiliary source and the conference itself is terminatedvia the Auxiliary Terminated (e.g. mtAuxiliaryTerminatedEvent) event 611and the conference terminated event 607 as illustrated in 600 in FIG. 6.This notifies the application that the conference is terminated, andteleconference data should no longer be transmitted. Any additionalclean up operations are then performed by the application, and thesource may be discarded.

A typical application's initialization is shown as process 700 of FIG.7. The application program makes a number of API calls in order to setvarious parameters associated with the member or potential participant.First, an application may cause the conference component to set itscapability at step 702 if it is different than the default. The call to“MTConferenceSetMessageCapabilities” causes the conference component torecall in a store the specific application capabilities within theconference component for the specific conference which are later usedduring transmission of messages to alert recipients that the senderapplication has certain functional capabilities prior to theestablishment of a connection between the sender and the receiver. Eachcapability has associated with it a type, version, and “desire” of thecapability. Each desire for each capability type may be flagged as:

-   -   1. optional;    -   2. desired;    -   3. required; or    -   4. a negotiation message.        These types of capabilities are included in a capabilities list        which is transmitted to endpoints, as will be described below.        An “optional” capability is a message which is not required to        be exchanged before setting up a conference. A “desired”        capability is one which is not required that it be exchanged        before setting up a conference, however, it is preferred that it        is. A “required” capability is one which requires that a message        be exchanged before setting up a conference. This may include        access control or other messages which are transferred prior to        setting up a conference. An access control capability may        include the transmission of a account number and password prior        to the commencement of a teleconference. A “negotiation message”        is a capability which indicates that the application wishes to        query the receiving application. In the case of a negotiation        message capability, the type field associated with the        capability allows the requests of information about the        applications prior to the establishment of a conference (e.g.        about the type of software and hardware components the        application is interested in, such as sound). Any other types of        exchanges which require negotiated information between        applications may be set.

Once all individual capabilities have been set by the issuance of “SetCapabilities” API calls (e.g. MTConferenceSetCapabilities) to theconference component at step 702, a member may set its operating mode atstep 704. The mode will be contained within a mode mask value which issent in the API call to the conference component, and moreover, isincluded in certain messages transmitted from the conference componentin the sender to the conference component in the receiver. The mode maskspecifies the characteristics of a conference that the member makesavailable. Different capabilities, modes, and other initializationoperations shown in FIG. 7 may be set for any number of conference typeswhich are made available by the member. At any rate, the default modeincludes the following values:

-   -   1. send media;    -   2. receive media;    -   3. shareable; and    -   4. joiner.        The “send media” mode flag indicates that the member intends to        send media data in its conferences. Most members will want to        send media, however, there will be instances where the member        will be a receive-only member, thus the send media mode flag        will not be set. The receive media mode flag indicates that the        member intends to receive media in conferences. In the case of a        send-only member (e.g., a server providing a real-time video        and/or audio source), will have the receive media mode flag set        to “off” (e.g., a numeric value ‘0’). The “shareable” mode flag        indicates that the member is willing to share the conference        media data with new conference members. Thus, in the instance of        a send-only media server, the shareable mode flag would be set        indicating that new members can receive the conference data.

The “joiner” mode flag indicates that all conference members are allowedto interact. This could allow two-way transmission between each of theconference members. However, the setting of this flag to “off” (e.g., anumeric value ‘0’) results in broadcast type conferences wherein onemember sends media data to other conference members, but the individualconference members do not exchange any media data among themselves. Eachof these mode flags is transmitted at the beginning of a connection(e.g., contained within the “hello” message 1400 in FIG. 14).

By default, the conference component establishes conferences that arefully two-way media data capable, shareable, and joinable. If differentcharacteristics are desired, then the application must call “set mode”(e.g. MTConferenceSetMode) at step 704, along with the appropriateflag(s) set. Conference mode settings are stored and associated with aparticular conference ID in the sender's conference component so thatwhen messages are created for that conference ID, the appropriate modeflags are transmitted along with the initialization or other messagessent before any other communications.

In addition to the capabilities and mode settings at steps 702 and 704,a time-out value associated with calls placed from the member may be set(e.g. using the API call MTConferenceSetTimeOut). The time-out value isthen included at the beginning of certain messages preceding aconference in order to enable a recipient to determine when the callerwill stop listening for responses. This allows certain features to beincorporated into participant conference components such as the smarttriggering of events based upon context. For example, if the recipientis receiving a call, but a user does not wish to take the call at thattime, the recipient's conference knows the time-out occurs and can takecertain context-dependent action (e.g., forward the call, send amessage, etc.).

The application can then involve an API call “Listen for Call” (e.g.MTConferenceListen) which implements steps 708 and 710. At step 708,using the underling transport to which the system is connected, a highlevel address is registered and published. This then allows otherpotential participants in the system to call the member. Theregistration and publication of the address is implementation-dependent,depending upon the media to which the system is connected. Then, at step710, the conference component waits for incoming calls.

The conference component in the member enters an idle state whereinincoming messages, alters for the transport component, API and callswill be detected and acted upon. Note that the capabilities, mode, andtime-out values are all optional, and the default settings may be usedby the member if none of these functions is required by the application.In the call to the MTConferenceListen function, the application mustspecify the networks on which the member is willing to accept calls. Theconference component proceeds to register the member on those networks,doing whatever is appropriate in the various network contexts, and sendan mtListenerStatusEvent to the application to specify whether theregistration attempt was successful. After listeners are operational, ifanother application desires to establish communication with theapplication, then an mtIncomingCallEvent is forwarded to theapplication.

FIGS. 8-10 show examples of the various message exchanges between twoendpoints. Messages are generated by conference component 400 dependingupon operating context, and application calls. FIG. 8 shows an exampleof a calling sequence for setting up a conference between two endpoints.Upon the commencement of a call from a first endpoint such as 810 shownin FIG. 8, and a second endpoint such as 820 shown in FIG. 8, a“capabilities” message 802 is transmitted from the endpoint 810 to theendpoint 820 if they have been set by the caller. The exchange of“capabilities” messages 802 and 812 between endpoint 1 810 and endpoint2 820 are exchanged after a control channel has been opened on thetransmission medium between the participants in animplementation-dependent manner (e.g. by invoking MTConferenceCall).This identifies the capabilities of each of the endpoints, if thecapabilities of the application are desired to be transmitted. Oncecapabilities have been transmitted from each endpoint, each endpointfurther transmits Hello messages 804 and 814 to identify themselves. Thedetails of the capabilities, Hello, and other messages illustrated inthe figure will be discussed below. The Hello message is the first stepin establishing a conference, and allows conference components indifferent systems to exchange basic identification and mode information.Subsequent to the exchange of Capabilities messages (if any), and theHello messages 804 and 814, the endpoint 1 810 wishing to establish theconference sends a call message 806 to endpoint 2 820. Subsequentthereto, if endpoint 820 desires to engage in the teleconference withendpoint 1 810, it sends a response message 816 to endpoint 1 810. Then,upon the transmission of the call message 806 and the receipt of theresponse message 816, a teleconference is then established betweenendpoint 1 810 and endpoint 2 820. The details of the process stepsperformed within each endpoint are discussed with reference to FIGS. 11and 12.

FIG. 9 illustrates a “Join” protocol process. This is similar to thecalling process, however, a “Join” message 906 is sent to the secondendpoint instead of the “call” message 806. The details of a Join arediscussed with reference to FIGS. 26a-26c below.

FIG. 10 illustrates the messages exchanged for a terminate message. Asillustrated, an endpoint may issue a terminate message to terminate ateleconference. No response is required for any receivers.

FIG. 11 shows the process steps performed by a first participant (e.g.,endpoint 1 810) wishing to establish communication with a secondparticipant system (e.g., endpoint 2 820). First, at step 1102, thecaller via implementation-dependent means, accesses the address of theparty it wishes to call, either by reference to an internal store,referencing a server or other implementation-dependent manner. Once thishas been performed, the application invokes the API callMTConferenceCall in order to call the party at step 1104. Responsivethereto, either a failed event 1106 (mtFailedEvent) is received by thecaller, or a ringing event 1108 (mtPhoneRingingEvent) when the callmessage has been transmitted to the second participant. In the event ofa ringing event, the endpoint can then get the capabilities, mode andthe name of the endpoint such as by examining the data contained in theCapabilities message 812 and/or the Hello message 814. Any “required”communication between the caller and receiver may also be performed.Then, the first sender can appropriately configure itself for the secondendpoint. Once any necessary message exchanges and/or configurationshave been performed in the caller, then the caller will either receive aMemberRefused event 1112 (e.g. mtRefusedEvent), for example, if thecalling member does not provide the necessary access control subsequentto the call message, or, a MemberReady event 1116. Also, a failed event1106 can be detected at any time, followed by a MemberTerminated event114. In the case of a MemberRefused event 1112, then the conferencecomponent will generate a MemberTerminated event 1114, and a conferenceterminated event will then be issued indicating the end of theconference. Once capabilities have been obtained, any requiredcapabilities are checked for at step 1113 (e.g. such as any actions thatmust be performed before the receiver accepts the call). Subsequentthereto, a ConferenceReadyEvent1115 (e.g. MTConfReadyEvent) and aMemberReady event 1116 (e.g. mtMemberReadyEvent) can be received by theapplication, then the endpoint can then engage in the exchange ofmessages typical during a conference, thus commencing the conference atstep 1118.

As shown in FIG. 12, the sequence of steps performed by the receiver isillustrated. For example, at step 1202, the receiver application willdetect an incoming call event 1202. Subsequent thereto, the receiver canthen determine mode, capabilities, caller's name, conference name,and/or return address of the party wishing to engage in the conference.The mode can also be checked for at step 1206. Once this has been done,then a time-out check, if any, at 1208 can be performed in the receiver.The time-put check may be performed, depending upon an application'simplementation, by checking the time-out field shown at field 1504 inFIG. 15, which indicates how long the transmitter will wait prior totiming out and generating a CallFailed event (e.g. mtFailedEvent) inorder to terminate the call. In this case, according to implementation,the receiver may do a variety of things, for example, issuing a busysignal to the transmitter, issuing a message to the caller or, takingsome action, such as forwarding the call to another party. Thus, theembedding of the time-out field 1504, within the initial connectionmessage “Hello,” provides for certain intelligent features in thepotential participants of a teleconference. Once any mode checks, ifany, have been performed at step 1206, then at step 1208 a time outcheck, if any, may be performed. Any user interaction may take place atstep 1209. The receiver will then issue a reply at step 1210. The replymay indicate either refusal to answer the call (e.g., due to accesscontrol, or the participant already engaging in another conference), orchoose to respond to the call in the affirmative indicating that theteleconference may commence. In the case of a refusal, theMemberTerminated 1220 event (mtMemberTerminatedEvent) is issued to theapplication. In the case of the member answering, the MebmerReady event1218 (mtMemberReadyEvent) is issued indicating that the medium channelis open and the conference can commence.

Conferencing Messages

Conference components exchange a number of messages in order toestablish, maintain, and terminate conferences. Conference componentsalso send messages that encapsulate user data, that is, the data that isexchanged by the programs that are using the conference.

After establishing a transport connection but prior to establishing aconference channel with a remote system, a conference member may sendeither a Capabilities message 1300 or an Auxiliary message 1700. Themember then sends a Hello message 1400 to identify itself, specificallyits mode of operation (send media, receive media, shareable, or joiner)followed by a Call message 1500 (to set up a conference) or a Joinmessage 1800 (to join to an ongoing conference). The remote member sendsa Response message 1600 in answer to the Call or a Join message 1800.Once a conference is established, a member can combine calls orconferences by sending a Merge message 1900. Conference members may sendor receive a Terminate message 2300 to end a conference. Connectionsinitially are point-to-point between members of a conference. If thetransport medium supports multicast addresses and more than one memberis participating in a conference, a broadcast to a multicast address canbe used as an optimization. The conference component uses theBroadcastRequest and BroadcastAck messages 2400 and 2500 to negotiatethe transition from point-to-point to mutlipoint connections usingmulticast addresses.

All messages supported in the conference messaging protocol are precededby a 2-byte character identifying the message type. For example for acapabilities message shown in FIG. 13, field 1302 contains a ‘K’. Allmessages are further terminated by a NULL such as that shown in field1308 of FIG. 13. The Capabilities message 1300 allows a potential memberto tell other potential conference members what it can and cannot do ina conference. Each member sends this message before sending the “Hello”message (1400 in FIG. 14) if capabilities other than the default aresupported.

Field Size Value type 1302 2 bytes ‘K’ delimiter 1304 1 byte newlinecapabilitiesList 1306 0-n bytes (alphanumeric) terminator 1308 1 byteNULLcapabilitiesList 1306

-   -   The member's capabilities. This field is optional. If specified,        it contains a list of the member's capabilities. An application        specifies its capabilities by calling the conference component's        MTConferenceSetMessageCapabilities function.

The Capabilities message 1300 shown in FIG. 13 informs other potentialconference participants about a member's capabilities. Thesecapabilities relate directly to messages the member either supports orrequires, one capability for each conferencing message type that thecomponent supports. The messages themselves are defined by the type ofapplication the member is running. For example, video phone applicationsand chat lines deliver different services, and use different messages todo so. As a result, the capabilities a member supports will change inlight of the application that is participating in the conference.Entries in the capabilitiesList field my request information from theremote system. By setting an entry's “desires” field (2010 of FIG. 20)mtNegotiationMessageCapabilities (‘N’), a conference member can queryfor specific information (e.g. about a given component type, such as acodec, hardware/software features supported, etc.). The type field cancontain the component type value.

In response to a negotiation Capabilities message, the remote memberformats a user data message, for example, containing available componentsubtypes. Note that this list may contain duplicate entries and entrieswith a value of NULL. To parse this array, a member must determine thearray's size. After sending a Capabilities message 1300, the membersends a Hello message 1400 to establish a conference.

A Hello message (e.g., 1400 of FIG. 14) is sent at the start of aconference by each endpoint. The Hello message identifies basiccapabilities of the sender and the mode in which it will operate. Itcontains the following:

Field Size Value type 1402 2 bytes ‘H’ MinimumVersion 1404 1-n bytes(numeric) delimiter 1406 1 byte colon maximumVersion 1408 1-n bytes(numeric) delimiter 1410 1 byte newline conferenceMode 1412 1-n bytes(numeric) delimiter 1414 1 byte newline name 1416 1-n bytes(alphanumeric) delimiter 1418 1 byte newline terminator 1420 1 byte NULLminimum Version 1404

-   -   The oldest version of the conference protocol supported by the        sending component        maximum Version 1408    -   The newest version of the conference protocol supported by the        sending component.        conferenceMode 1412    -   The desired conference operating mode. This field contains a        value that corresponds to the operating mode the sender desires        for this conference. Applications specify their desired mode by        a SetMode API call (e.g. MTConferenceSetMode discussed above).        name 1416    -   The name of the prospective conference member. This name        identifies the entity that wants to join the conference, and may        represent either an auxiliary data source or a new user.        Applications specify a user name by calling the        MTConferenceListen API call. The auxiliary name is specified in        a MTAttachAuxiliary API call.

The Hello message 1400 is the first step in establishing a conference.This message allows conference components on different systems toexchange basic identification and capability information. Before sendinga Hello message 1400, a conference component may send either aCapabilities 1300 or an Auxiliary message 1700. The type of message sentdepends upon the role the member anticipates playing in the conference.If the member is looking to join or start a conference, the conferencecomponent sends a Capabilities message. If the member is setting up anauxiliary media data source, the component sends an Auxiliary message1700. Following this message, the conference component can enter thecall setup phase by sending the Call message 1500. If the member wantsto provide an auxiliary data source to an existing conference, or joinan existing conference, the component sends the Join message 1800.

Call message 1500 of FIG. 15 begins the process of establishing aconference connection between two possible participants. This is akin todialing a number from a phone directory.

Field Size Value type 1502 2 bytes ‘C’ callTime-out 1504 1-n bytes(numeric) delimiter 1506 1 byte tab ConferenceName 1508 1-n bytes(alphanumeric) delimiter 1510 1 byte newline callingConfID 1512 1-nbytes (alphanumeric) delimiter 1514 1 byte newline terminator 1516 1byte NULLcallTime-out 1504

-   -   The amount of time the calling component is willing to wait for        an answer. This field specifies the number of ticks ( 1/60 of a        second) the calling component will wait before deciding that the        call has not been answered. Called components must respond        within this time period. This value may be used by a potential        responder for taking some automatic action if the user doesn't        answer before the timeout.        ConferenceName 1508    -   The conference name. If the caller is establishing a conference,        this is the name the caller has assigned to the conference. If        the caller is connecting to a conference server, the is the name        of the server's conference. Applications set the conference name        by calling the MTConferenceCall function.        callingConfID 1512    -   The caller's unique conference identifier. This field uniquely        identifies the caller's conference endpoint on the network.        Conference components create conference identifiers on behalf of        calling applications which are unique within the conference        component. Call ID's are discussed with reference to 2200 of        FIG. 22.

The Call message 1500 shown in FIG. 15 begins the process ofestablishing a conference between two participants. This message can beused in two ways. First, this message can create a conference betweentwo participants. In this scenario, the caller assigns a name to theconference, so that other possible participants may join later.Alternatively, this message can request to join a conference that ismanaged by a conference server on a network. For example, the serverwill allow incoming calls, but the function of the server is to mergethe new conference due to the call with other ongoing conferences. Inother words, the server acts exclusively as a “joiner” and does notsupply media data. Once the call is set up, the caller can beginexchanging user data with other conference participants.

The response message 1600 of FIG. 16 is sent in response to Call or Joinmessages 1500 or 1800.

Field Size Value type 1602 2 bytes ‘R’ callResponse 1604 1-n bytes(signednumeric) delimiter 1606 1 byte newline destinationConfID 1608 1-nbytes (alphanumeric) delimiter 1610 1 byte newline terminator 1612 1byte NULLcallResponse 1604

-   -   The result. This field indicates the result of the preceding        Call request. This field is set to ‘0’ if the request was        successful. Otherwise, it contains an appropriate result code.        destinationConfID 1608    -   The other endpoint's unique identifier. This field identifies        the other participant in the conference.        The Response message 1600 allows the caller to determine the        success of a Call or Join request. The Response message 1600        indicates how the user at the remote system reacted to the call        (for example, whether the user answered the call). The        callResponse field 1604 contains the request's result code. If        non-zero, an error occurred and the request was not successful.        Otherwise, the destinationConfID field 1608 identifies the        endpoint with which the caller may now communicate.

The auxiliary message 1700 allows one member to alert the other membersof a conference that it is about to provide an auxiliary media datasource (a source associated with an ongoing conference). This messagemay be used in place of the Capabilities message 1300 if a participantis being alerted about the presence of an auxiliary media source. Themember sends this message before sending the Hello and Join Messages1400 and 1800, and then proceeds to adding an auxiliary data source tothe conference.

Field Size Value type 1702 2 bytes ‘A’ parentConfID 1704 1-n bytes(alphanumeric) delimiter 1706 1 byte newline terminator 1708 1 byte NULLparentConfID 1704

-   -   The member's conference identifier. This field identifies the        member's existing conference endpoint (the conference identifier        the member supplied in the Call messages when it first joined        the conference). This allows other conference participants to        identify the source of the auxiliary data within each        participant.

The Auxiliary message 1700 informs other conference participants that amember is about to provide an auxiliary conference data source. Forauxiliary data sources, this message replace the Capabilities messageduring early interactions. The member must send this message to eachconference participant. The member then sends a Hello 1400 and a Joinmessage 1800 to each participant. Other participants then accept the newdata source by accommodating the Join request.

A Join message 1800 of FIG. 18 allows a member to join an existingconference, given that conference's identifier. This message is usefulfor adding auxiliary data sources to an existing conference, and formerging two existing conferences.

Field Size Value type 1802 2 bytes ‘J’ destinationConfID 1804 1-n bytes(alphanumeric) delimiter 1806 1 byte newline callingConfID 1808 1-nbytes (alphanumeric) delimiter 1810 1 byte newline memberList 1812 0-nbytes (alphanumeric) terminator 1814 1 byte NULLdestinationConf ID 1804

-   -   The remote endpoint's unique conference identifier. This field        identifies the conference to join on.        callingConfID 1808    -   Unique conference identifier. This field uniquely identifies the        caller's conference endpoint on the network. Conference        components create conference identifies on behalf of calling        applications. If the message is adding an auxiliary media data        source, this is the auxiliary's identifier.        memberList 1812    -   A list of other conference participants. This list identifies        all other known conference participants that are willing to        exchange data with new participants (that is, they have the        Joiner Mode Mask [e.g. mtJoinerModeMask] set in their conference        mode). The conference component can connect with each        participant with whom it is not already connected. If the        message is adding an auxiliary (via the issuance of an auxiliary        message 1700), this list contains the endpoint identifier of        each participant to which the caller is making the auxiliary        available. It is up to each of them to respond.    -   This is a list of conference endpoint identifiers; each element        in the list is followed by a newline character.

The Join message 1800 allows a member to add an auxiliary data source toan exiting conference or to merge two existing conferences. The callersends this message to members of the conference in response to a mergeror join request instead of a call message.

The Merge message 1900 of FIG. 19 combines two conferences. Recipientsof this message connect with the listed members with whom they are notalready connected.

Field Size Value type 1902 2 bytes ‘M’ conferenceName 1904 1-n bytes(alphanumeric) delimiter 1906 1 byte newline myConfID 1908 1-n bytes(alphanumeric) delimiter 1910 1 byte newline memberList 1912 0-n bytes(alphanumeric) terminator 1914 1 byte NULLconferenceName 1904

-   -   The new conference name resulting from the merge. This is the        name that was assigned to the conference when the conference was        established. Applications specify the conference name by calling        the MTConferenceCall API function.        myConfID 1908    -   Unique conference identifier. This field uniquely identifies the        caller's conference endpoint in the target conference.        Conference components create conference identifiers on behalf of        calling applications.        memberList 1912    -   A list of other conference participants. This list identifies        other current conference participants. This list contains the        endpoint identifier of each new participant. This is a list of        conference endpoint identifiers; each element in the list is        followed by a newline character.

The Merge message causes the combination of two conferences. This is themechanism for creating conferences with more than two participants. Thecaller sends this message to each existing conference member, specifyingthe conference's name. Each endpoint establishes communications with anynew endpoints. By convention, the endpoint with the higher conferenceidentifier value establishes the connection (to avoid duplicate ormissed connections). Members of the conference receive a Join message1900 instead of a Call message 1500 when contracted by each new member.

Field Specifics

A capabilities list such as shown in FIG. 20 (e.g., field 1306) containsinformation about the message supported by a conferencing application.The list consists of zero or more lines of information; each linespecifies a single capability and consists of the following fields:

Field Size Value type 2002 4 bytes (alphanumeric) delimiter 2004 1 bytetab version 2006 1-n bytes (numeric) delimiter 2008 1 byte tab desires2010 1 byte (alphanumeric) delimiter 2012 1 byte newlinetype 2002

-   -   Identifies a message by reference to a unique type value.        version 2006    -   Message version number. Specifies the most-recent version of the        message that the application supports.        desires 2010    -   Support level. This field indicates the level of support        required by the application. Possible values are:        -   mtMessageOptionalCapability            -   Optional. Indicates that the message is optional. The                value corresponding to this option is ‘O’.        -   mtMessageDesiredCapability            -   Desired. While still optional, this value indicates that                the application prefers to receive this message early in                the call (e.g. prior to establishing a call, one member                may request that the recipient send his business card                for long-term storage). The value corresponding to this                option is ‘D’.        -   mtMessageRequiredCapability            -   Required. The application must receive this message. The                value corresponding to this option is ‘R’.        -   mtNegotiationMessageCapability            -   Negotiate. The application wants to learn about the                recipient's facilities. The value corresponding to this                option is ‘N’.

Conference identifiers such as 2200 shown in FIG. 22 uniquely identify aconference endpoint. Each endpoint represent a data source or sink forthe conference. Note that a single system may have more than oneconference endpoint (e.g., an auxiliary) in a given conference, and mayhave more than one conference at a time. A conference endpoint consistsof the following fields:

Field Size Value UniqueID 2202 1-n bytes (numeric) separator 2204 1 bytespace name 2206 1-n bytes (alphanumeric)UniqueID 2202

-   -   Unique numeric identifier. This field contains a unique numeric        endpoint identifier. Each conference component assigns its own        identifiers in order to guarantee uniqueness within the context        of a given name specified in the name field 2206.        name 2206    -   A unique name. Identifies the system on the network. The name is        unique within the context of a given transport interface. It        includes the type of the selected transport and network        interface.

A member list such as 1812 of FIG. 21 is an array of zero or moreconference identifiers 2102, 2110, etc. Each entry in the array isdelimited by a newline character.

The Terminate message 2300 of FIG. 23 ends a conference, closing amember's communications with the participants to which it sends themessage.

Field Size Value type 2302 2 bytes ‘T’ delimiter 2304 1 byte newlineterminator 2306 1 byte NULLThe Terminate message 2300 is the last step in ending a member'sparticipation in a conference. This message ends the member's conferencecommunication with all participants to which it sends the message. If amember is leaving a conference altogether, it must send this message toeach conference participant.

The BroadcastRequest message 2400 allows a member to find out if anotherconference member can accept broadcast (multicast) messages.

Field Size Value type 2402 2 bytes ‘B’ subtype 2406 1 byte ‘R’ delimiter2408 1 byte tab multicastAddress 2410 1-n bytes (alphanumeric) delimiter2412 1 byte newline terminator 2414 1 byte NULLsubtype 2406

-   -   The broadcast message subtype. This field must be set to ‘R’.        multicastAddress 2410    -   The proposed multicast address. This field contains the        multicast address on which the member proposes to send broadcast        messages.

The BroadcastRequest message 2400 allows a member to determine whetheranother conference member can accept broadcast messages over a givenmulticast network address. The recipient indicates its ability tosupport the broadcast messages by sending a BroadcastAck message 2500(described below). If the recipient cannot support broadcast messagingor cannot access this particular broadcast transmission, the callingmember should continue to send point-to-point messages to the recipient.

The BroadcastRequest message 2400 is typically uses as part of thenegotiation process that follows merging two conferences or the joiningof any new members to a conference. As an optimization, conferenceparticipants may choose to set up broadcast capabilities as amore-efficient alternative to maintaining several differentpoint-to-point connections.

The BroadcastAck message 2500 allows a member to respond to aBroadcastRequest message 2400.

Field Size Value type 2502 2 bytes ‘B’ subtype 2504 1 byte ‘A’ delimiter2506 1 byte tab broadcastResponse 2508 1-n bytes (signed numeric)delimiter 2510 1 byte newline terminator 2512 1 byte NULLsubtype 2504

-   -   The broadcast message subtype. This field must be set to ‘A’.        broadcastResponse 2508    -   The result. This field indicates whether the member can support        the multicast address proposed in the BroadcastRequest message        2500.

The BroadcastAck message 2500 allows a member to indicate whether it canreceive messages over a proposed multicast address. Another conferenceparticipant proposes a multicast address by sending a BroadcastRequestmessage 2408. If the receipt can support that address, it sets thebroadcastResponse field 2508 to ‘0’. Otherwise, the broadcastResponsefield 2580 contains an appropriate non-zero result code. This message istypically used as part of the negotiation process that follows mergingtwo conferences. As an optimization, conference participants may chooseto set up broadcast capabilities as a more-efficient alternative tomaintaining several different point-to-point connections.

Join operations have the protocol illustrated in FIG. 9. FIGS. 26a-26cillustrate the process steps performed in a transmitter and receiverduring join operations. FIG. 26a shows a process 2600 which includes theprocess steps performed by a transmitter of a join message or anymessage containing a member list. This may occur, for example,responsive to an auxiliary or merge message. First, the transmittercreates a join message at step 2602. The destination conference ID andcalling conference ID's are added to the message at step 2603. Then, atstep 2604, a member is appended to the members listed in the joinmessage. This is shown in more detail in FIG. 26b. A transport levelconnection with the member to receive the join is then performed at step2605. Subsequent thereto, the message is then sent to any recipients atstep 2606.

FIG. 26b illustrates the “append members” function 2604 shown in FIG.26a for appending members to a member list. The function starts at step2610 which determines whether the member is a “joiner.” If so, thenadditional members can be appended to the join. If not, then thefunction ends and the join message with the single member is transmittedas shown in FIG. 26a. At 2612, the next member is retrieved according tothe conference ID. At step 2614 it is determined whether there are anymore members in the specified conference ID. If not, the process iscomplete. If there are more members and the shareable mode flat is set,as detected at step 2616, then the member is added to the member list atstep 2618. In this manner, during a merge operation, other participantsreceiving join messages can determine if conference membership haschanged, requiring additional join messages to be transmitted byreceiving members.

FIG. 26c shows the steps performed by a receiver of a join message.First, at step 2652, the destination conference ID contained in the joinmessage is looked up by the receiver in a locally-stored currentconferences history table (e.g. 2900 of FIG. 29). This keeps track ofpreviously used conference ID's for any currently active conferences. Ifthe conference ID has changed, the member can then complete the join byreferencing an old conference ID and the current conference ID in themember. This allows for conference merge and auxiliary messages fromwidely distributed members in a network. If the conference ID can't befound, as detected at step 2654, then the connection is refused at step2656, by the issuance of an appropriate response message, and the joinfails. If the conference ID has been found, then, at step 2660, theconnection is added to the list of participants for the conference. Atstep 2662, a Response message that the join can be performed is sent tothe sender of the join. Then, the membership of the members contained inthe member list of the join can then be performed as shown in FIG. 26d.

The merge membership function 2664 is shown in more detail in FIG. 26d.First, it is determined at step 2678 whether the member mergingmembership is shareable. If so, then at step 2680, it is determinedwhether there are any more members in the member list. If not, thefunction is complete. If so, the next member from the membership list isretrieved at step 2682. If the participant is already connected, is themember or is the member's own auxiliary source, as detected at step 2684then the process returns to step 2680. It is determined, at step 2686,whether this party is going to initiate the join with this member in themember list. This prevents conflicting join messages from being receivedand acted upon in the network. This is accomplished by determiningwhether the recipient's conference ID is greater than the callingparty's conference ID. In this case, this party will take action on thejoin (e.g. place the call to the other party to accomplish the join).Operations necessary to accomplish the join then take place starting atstep 2688. At this step, transport level connections are established.Once established, capabilities, if any, (or an auxiliary message, in thecase of an auxiliary source), hello, and join messages are sent at step2690. The member then waits for a response to the join, and if receivedin the affirmative, the conference component issues MemberReady to theapplication. This process continues until all members in the member listhave been processed.

Merge Operations

Merge operations are initiated using a “Merge” message (e.g., 1900 ofFIG. 19) which indicates to a participant that two existing conferencesshould be merged. This is according to the conference ID containedwithin the field 1908 of Message 1900. Each Merge message containswithin it a memberList 1912 which allows the participating members totransmit Join messages to all the members which have been listed in thememberList. This further allows changing membership and conference IDduring the course of a merge operation to be tracked so that correctconference ID's and conference membership may be maintained until afterthe merge. A merge operation is graphically illustrated with referenceto FIGS. 26a and 26b. For example, at a first time period as illustratedin FIG. 26a, conference member ID may be engaging in two conferencesdenoted 1 and 2 with several other members, A, B, and C. The member thenproceeds to issue Merge messages to the members of conferences. That is,member D issues join messages to members A, B and C to Merge theconference 2 (denoted B₁ and C₁). At the end of the operation, membersA, B, C, and D all have point-to-point communication channels and thenew conference ID is the same, (A₁, B₁, C₂, D₁, respectively in each ofthe members). The mechanics of this operation are described briefly withreference to FIGS. 28a-28b. That is, the two separate conferences arenow denoted by the same conference ID's in each of the members.

FIGS. 28a-28b show the steps taken during a merge operation by theconference component in the transmitter and receivers (if any) of amerge message. FIG. 28a shows the process steps taken by a transmitterof a merge request. The member first combines the conference ID's of theold and new conference in it's internal store at step 2802. Then, atstep 2804, the member creates the merge message and appends each of themembers of the conference to the members list in the message via theappend members routine 2604 (discussed above) in order to ensure fullconnectivity among all conference members. Then, at step 2806, the mergemessage is sent to all participants in the merge.

FIG. 28b shows process steps taken in a receiver receiving a mergemessage. Once a merge message has been detected (step 2812), the mergerecipient recalls in a local store for example, the conference name andthe conference ID at step 2814. Then, as discussed with reference toFIG. 26d, above, a merger of membership is performed (e.g. process2664), and the process is thus complete at step 2816.

In addition to using conference ID's for performing merge and subsequentjoin operations, contained within each Merge and Join message is a listof members of the conferences being merged or joined. These are includedin the memberList fields 1812 or 1912 of messages 1800 or 1900. Forexample, due to propagation delays in a networking system, oldconference ID's may still exist in peripheral participants, andtherefore during merging and or joining operations, conference ID's maybecome invalid due to members merging conferences, etc. . . . , orreference conference ID's which no longer exist. Thus, contained withineach conference component in a member is a current conferences tablesuch as 2900 shown in FIG. 29. The current conferences history tableallows a member performing a merge or join operation to determinewhether in fact conferences to be merged use old conference ID's. If so,then the new conference ID may be used to transmit to the participantsreceiving the join messages, and/or be matched to the appropriateconference ID. Thus, the member performing the merge operation canreference by way of the current conference ID 2901 contained within themerged conferences table, or other conference ID values 2902, containinga variable length list of conference ID's, to which the currentconference ID refers. Conference entries are deleted at the end of aconference by the conference component. If a merge occurs at aperipheral location and a conference ID becomes invalid, then the listof conference ID's for an existing conference ID can be referenced byreferencing the merged conferences history table.

Multicast

FIGS. 30a and 30b illustrate a process which is performed as anoptimization if multiple participants within a conference supportmulticast address broadcast capabilities. First, it is detected at step3001 whether there are any more transport media to be examined. If so,then the next is retrieved at step 3002, and at step 3003 it isdetermined whether two or more participants are in the same conferenceand are on the same transport medium. If so, and the transport mediumsupports multicast at step 3004, then the multicast capabilities of thetransport medium are activated at step 3006. If so, and the multicastcapabilities are working at step 3008, then step 3008 proceeds to step3012. If it is not working, as detected at step 3008, then the processis aborted at step 3010. At step 3012, a multicast address which may beused for the transport medium is retrieved at step 3012. Then, at 3014,Broadcast Requests are sent in substantially the format as shown inMessage 2400 of FIG. 24, to all the participants detected at step 3002supporting multicast. The process then awaits BroadcastAsk (in theformat 2500 shown in FIG. 25) in order to determine whether themulticast address is available for each at step 3016. If so, then foreach BroadcastAck determined to be received at step 3018, and it isdetermined whether the BroadcastAck was positive (due to the responsevalue contained in field 2508 of FIG. 25). At step 3022, if the responsewas positive, then the point-to-point connection is deactivated. Onceall the Broadcast Acks have been received (or have timed-out), then itis determined at step 3024 whether there was a Broadcast Ack receivedfor each Broadcast Request message sent. If not, then the process iscomplete. If so, however, step 3026 determines whether there were anypositive BroadcastAck for the multicast. If not, then multicast isdeactivated, and point-to-point communication continues to be used forcommunication with the other members (this optimization cannot beperformed). The process is thus complete.

Auxiliary Operations

An auxiliary media source can become part of an ongoing conference. Themedia source is associated with an ongoing conference by a invokingreference to the main conference stored in each conference component(e.g. by the API call MTConferenceAttachAuxiliarySource), however, it istreated as a separate conference in each conference component. Forexample, as illustrated with reference to FIG. 31, a first conferencereferred to by conference ID 23B in member B, may be notified of anauxiliary source having conference ID 17A from member A. Note thatsimilar to the protocol illustrated with reference to the Capabilitiesand Hello messages in FIGS. 8 and 9 above, the Auxiliary message may besent in place of a Capabilities message between a first endpoint and asecond endpoint as illustrated in FIG. 32. The timing of the messages isillustrated with reference to FIG. 32. Similar to the capability andcall protocol illustrated with reference to FIG. 8 above, the Auxiliarymessage 3202 is received from the first endpoint 3210, to notifyendpoint 2 3220 that an auxiliary source is available from the parentconference ID, as specified in parentConfID field 1704 of Axillarymessage 1700 of FIG. 17. Then, a Hello message 3204 is transmitted fromendpoint 1 3210 to endpoint 2 3220. Responsive thereto, endpoint 2 3220transmits capabilities message 3222 and Hello message 3224. Subsequentthereto, a Join message 3226 with the conference ID=23B is issued fromthe endpoint to 3220 with the conference ID of the source in order toindicate that the endpoint 3220 wishes to receive the auxiliary sourceAA, shown in FIG. 31. Subsequent thereto, all messages from source A torecipient B as illustrated in FIG. 31 reference the same conference ID23B for the ongoing conference between A and B. As illustrated in FIG.31, the “receive media” mode flag is set to not receive (!Receive) andfurthermore, the mode of the auxiliary source is not joiner (!Joiner)since it is a receive-only media source. Subsequent thereto, the secondendpoint 3220 sends a response message 3216 indicating that theauxiliary source has been successfully joined with the conference 23B.Subsequent thereto, both media messages for the conference ID 23B, andthe auxiliary source having conference ID 17A are treated as from thesame source (A) by the application. The details and mechanics of amember receiving an auxiliary source message are illustrated withreference to FIGS. 33 and 34.

FIG. 33 shows the process steps performed within a source of anauxiliary source. At step 3302, the next participant in the conferenceto which the auxiliary source will be attached is retrieved. It isdetermined, at step 3304, whether there are any more participants in theconference to which the auxiliary source will be attached. If any, then,at step 3306, auxiliary, hello and join messages are sent to theparticipant. If accepted via a positive response message (as shown inFIG. 32), the auxiliary then becomes available to the participant forthe receiver of the message. The process continues until step 3304determines that no additional participants in the conference should joinin the monitoring of the auxiliary.

FIG. 34 shows the steps taken by a receiver upon receipt of the initialauxiliary message. At step 3402, capabilities (if any), and hello aresent. At step 3404, the auxiliary source media starts to be received,and the conf ID of the parent conference is saved in the conferencecomponent of the receiver at step 3406. This allows the application todetermine that the auxiliary is associated with the patent media sourceby storage in the conference component for later retrieval at step 3408.If the auxiliary is received prior to the receipt of a join message,then the association of the auxiliary with the parent conf ID allows thelater association of the two from the application's standpoint.

An Example Session (FIGS. 35a and 35b)

An example session using the protocols described above is shown in FIGS.35a and 35b. The figures illustrate the flow of messages, from the viewof a first endpoint. After establishment of the connection between thestations using the transport component, the originating station sendscapabilities message 3502, and hello message 3504, specifying thecalling station's name “James Watt” with the mode mask set to 15 (allbits set—send, receive, joiner, shareable). Then, a call message 3506 istransmitted to the receiver along with the timeout value=19392confname=“some conference,” and the confID=“672 mtlkatlkJamesWatt:VideoPhone: VideoZone”. Simultaneously with the establishment of theconnect, corresponding capabilities, hello, and response are sent fromthe station entitled “Hillary Rodham” as illustrated by packets3508-3512, having the same mode.

Subsequent to the exchange of capabilities, hello, and call andresponse, a merge message 3514 is received by the first endpointincluding the conference name “Some Conference”, a conf ID=137 “mtlkatlkHillary Rodham: Video Phone: Video Zone” and a member list. The endpointthen processes the merge, placing a call sending capabilities, and helloto a member of the old conference, and a join along with the member listis shown by messages 3516, 3518, and 3520. Once the connection has beenestablished, capabilities and hello messages 3524 and 3526 are receivedfrom the recipient. Responsive to the join the recipient sends aresponse message 3528 with the result=0 (request successful). Subsequentthereto, the endpoint then attempts to use a multicast address bytransmitting broadcast request messages 3530 and 3532. The other membersrespond with broadcast Acks 3534 and 3536, allowing the use ofmulticast. The conference can then be terminated at any time by any ofthe members via the transmission of terminate messages to all of themembers, such as 3538 and 3540.

Thus, by use of the foregoing, connections between endpoints, such asfor teleconferences between teleconferencing systems, can be enables.This includes, but is not limited to, the exchange of capabilities andnotification of connections between endpoints, the addition of auxiliarydata streams to such connections, and the merging of exitingconnections. It will be appreciated that though the foregoing has beendescribed especially with reference to FIGS. 1-35b, that manymodifications made be made, by one skilled in the art, without departingfrom the scope of the invention as described here. The invention is thusto be viewed as limited only by the appended claims which follow.

1. In a system wherein a first endpoint is providing data to a pluralityof second endpoints each connected by a point-to-point communicationchannel with said first endpoint, an automatic method for optimizing thetransmission of said data to said plurality of second endpointscomprising the following steps: a. said first endpoint activating amulticast communication channel having a first multicast address andcommencing broadcast of said data over said multicast communicationchannel; b. Said first endpoint transmitting a request message to eachof said plurality of second endpoints in order to query each of saidsecond endpoints whether they can receive transmission broadcast to saidfirst multicast address; c. ceratin of said plurality of secondendpoints transmitting an acknowledgement message and said firstendpoint receiving said acknowledgement message; d. for each saidacknowledgment message received from said certain of said plurality ofsecond endpoints which indicates that said certain of said plurality ofsecond endpoints can receive transmissions broadcast to said firstmulticast address, deactivating said point-to-point communicationchannel with said first endpoint and said certain of said plurality ofsecond endpoints; and e. terminating said broadcast of said data andsaid multicast communication channel if at least two of said pluralityof second endpoints do not transmit said acknowledgment messagescontaining a positive acknowledgement.
 2. The method of claim 1 furthercomprising the step of receiving detach messages from certain of saidplurality of second endpoints, and if at least two of said plurality ofsecond endpoints are not receiving said data, then terminating saidbroadcast of said data and said multicast communication channel.
 3. Themethod of claim 1 wherein said each acknowledgment message includes aresponse code.
 4. The method of claim 3 wherein said response codeindicates whether each said certain of said plurality of secondendpoints can receive transmissions broadcast to said first multicastaddress.
 5. The method of claim 1 wherein said data includesteleconference data.
 6. The method of claim 1 further comprising, priorto said step of said first endpoint activating said multicastcommunication channel having a first multicast address, determiningwhether more than one of said plurality of second endpoints is coupledto said first endpoint on a single communication medium, and if not,aborting said method.
 7. The method of claim 6 further comprising, priorto said first endpoint activating said multicast communication channelhaving said first multicast address, determining whether said singlecommunication medium supports broadcasting to said first multicastaddress.
 8. The method of claim 1 wherein said data includesteleconference data between said first endpoint and said plurality ofsecond endpoints.
 9. An apparatus in a first endpoint for transmittingdata to a plurality of second endpoints receiving said data from saidfirst endpoint on point-to-point communication channels comprising: a. acircuit for activating a multicast communication channel having a firstmulticast address and commencing broadcast of said data over saidmulticast communication channel; b. a circuit for transmitting a requestmessage to each of said plurality of second endpoints in order to queryeach of said second endpoints whether they can receive transmissionsbroadcast to said first multicast address; c. a circuit for receivingacknowledgment messages, if any, from certain of said plurality ofsecond endpoints; d. a circuit for deactivating each said point-to-pointcommunication channel with said certain of said plurality of secondendpoints responsive to receiving each said acknowledgement message; ande. a circuit for terminating said broadcast of said data and saidmulticast communication channel if at least two of said acknowledgementmessages containing a positive acknowledgment are not received.
 10. Theapparatus of claim 9 further comprising a circuit for receiving detachmessages from others of said plurality of seocnd endpoints, and if atleast two of said plurality of second endpoints are not receiving saiddata, then terminating said broadcast of said data and said multicastcommunication channel.
 11. The apparatus of claim 9 wherein said eachacknowledgement message includes a response code.
 12. The apparatus ofclaim 11 wherein said response code indicates whether each of saidcertain of said plurality of second endpoints can receive transmissionsbroadcast to said first multicast address.
 13. The apparatus of claim 9wherein said data includes teleconference data.
 14. The apparatus ofclaim 9 further comprising a detection circuit operative prior to saidfirst endpoint activating said multicast communication channel havingsaid first multicast address for determining whether more than one ofsaid plurality of second endpoints is coupled to said first endpoint ona single communication medium, and if not, not activating said circuitsb and c.
 15. The apparatus of claim 14 further comprising, prior toactivation of said detection circuit a circuit for determining whethersaid single communication medium supports broadcasting to said firstmulticast address.
 16. An automatic method for adding an additional datastream to an existing communication session comprising: identifying theavailability of said additional data stream to an endpoint via a messagecontaining a reference to said existing communication session; receivingnotification of confirmation to connect; and establishing communicationto provide said additional data stream to said endpoint, said additionaldata stream being associated with said existing communication session.17. The method of claim 16, further comprising: notifying said endpointof the desire to connect to provide said additional data stream.
 18. Themethod of claim 16 wherein said additional data stream includes audioinformation.
 19. The method of claim 16 wherein said additional datastream includes a second media connection.
 20. The method of claim 16wherein said existing communication session includes a videocommunication session.
 21. The method of claim 20 wherein saidadditional data stream includes an audio source.
 22. The method of claim16 further comprising repeating the identifying, receiving, andestablishing steps for a second additional data stream, said second datastream becoming said additional data stream.
 23. The method of claim 16further comprising presenting an option to a user to add said additionaldata stream to said existing communication session.
 24. The method ofclaim 16 further comprising: transmitting a notification message to saidendpoint that said additional data stream will terminate; and responsiveto said notification message, said endpoint terminating receipt of saidadditional data stream, and removing said association with said existingcommunication session.
 25. The method of claim 24 further comprisingcontinuing to provide said existing communication session to saidendpoint.
 26. The method of claim 16 further comprising: receivingnotification that said endpoint is terminating receipt of saidadditional data stream; and responsive to said notification message,terminating transmission of said additional data stream to saidendpoint.
 27. The method of claim 26 further comprising continuing toprovide said existing communication session to said endpoint.
 28. Themethod of claim 16 wherein said reference to said existing communicationsession includes a conference identifier of said existing communicationsession.
 29. An apparatus for adding an additional data stream to anexisting communication session comprising: a first circuit coupled to acommunication interface, said first circuit creating and transmitting afirst message containing a reference to said existing communicationsession which identifies the availability of said additional data streamto an endpoint; a second circuit coupled to said communicationinterface, said second circuit receiving a second message from saidendpoint containing confirmation to receive said additional data stream;and a third circuit coupled to said communication interface, said thirdcircuit providing said additional data stream to said endpoint.
 30. Theapparatus of claim 29 further comprising a fourth circuit coupled tosaid first circuit and activating said first circuit for a secondadditional data stream, said second additional data stream becoming saidadditional data stream.
 31. The apparatus of claim 29 furthercomprising: a fourth circuit coupled to said communication interface andtransmitting a notification message to said endpoint that saidadditional data stream will terminate, and terminating said additionaldata stream, and removing said association with said existingcommunication session.
 32. The apparatus of claim 31, wherein saidexisting communication session continues to be provided to said endpointafter said additional data stream is terminated.
 33. The apparatus ofclaim 29 further comprising: a fourth circuit coupled to saidcommunication interface and receiving a notification message from saidendpoint that said endpoint is terminating receipt of said additionaldata stream and terminating said additional data stream, and removingsaid association with said existing communication session responsive toreceipt of said notification message.
 34. The apparatus of claim 33wherein said existing communication session continues to be provided tosaid endpoint after said additional data stream is terminated.
 35. Theapparatus of claim 29 wherein said reference to said existingcommunication session includes a conference identifier of said existingcommunication session.
 36. An automatic method for adding an additionalmedia stream to be associated with an exiting media stream comprising:identifying the availability of said additional media stream to anendpoint via a message containing a reference to said existing mediastream; receiving, from said endpoint, notification of confirmation toconnect; and establishing communication to provide said additional mediastream to said endpoint.
 37. The method of claim 36, whereinestablishing communication to provide said additional media stream tosaid endpoint comprises: associating said additional media stream insaid endpoint with said existing media stream.
 38. The method of claim36 wherein said additional media stream includes audio information. 39.The method of claim 36 wherein said additional media stream includes asecond communication session.
 40. The method of claim 36 wherein saidexisting media stream includes a video communication session.
 41. Themethod of claim 40 wherein said additional media stream includes anaudio source.
 42. The method of claim 36 further comprising repeatingsteps a-c for a second additional media stream, said second additionaldata stream becoming said additional media stream.
 43. The method ofclaim 36 further comprising presenting an option to a user to add saidadditional media stream.
 44. The method of claim 36 further comprising:transmitting a notification message to said endpoint that saidadditional media stream will terminate; and responsive to saidnotification message, terminating said additional media stream, andremoving said association with said existing media stream.
 45. Themethod of claim 44 further comprising continuing to provide saidexisting communication session to said endpoint.
 46. The method of claim36 further comprising: receiving a notification message that saidendpoint is terminating receipt of said additional media stream; andresponsive to said notification message, terminating said additionalmedia stream to said endpoint.
 47. The method of claim 46 furthercomprising continuing to provide said existing media stream of saidendpoint.
 48. The method of claim 36 wherein said reference to saidexisting media stream includes a conference identifier of said existingmedia stream.
 49. An apparatus for adding an additional media streamassociated with an existing media stream, said apparatus comprising: ameans for identifying an availability of said additional media stream toan endpoint via a message containing a reference to said exiting mediastream; a means for receiving a confirmation to connect from saidendpoint; a means for providing said additional media stream to saidendpoint.
 50. A computer readable-storage medium in a digital processingsystem that is transmitting an existing media stream to an endpoint,said medium containing executable computer program instructions whichwhen executed in said digital processing system cause said system toperform steps comprising: identifying an availability of an additionalmedia stream to said endpoint via a message containing a reference tosaid existing media stream; receiving a confirmation to connect fromsaid endpoint; providing said additional media stream to said endpoint,said additional media stream being associated with said existing mediastream.